home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 9076 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.2 KB
  1. Path: news.gate.net!not-for-mail
  2. From: dhaire@gate.net (doug haire)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Is USR going to support 42bis+ on future courier upgrades?
  5. Date: 25 Mar 1996 08:52:59 -0500
  6. Organization: CyberGate, Inc.
  7. Message-ID: <4j68fr$14go@navajo.gate.net>
  8. References: <4j2fv1$8kf@nnrp1.news.primenet.com> <4j2iun$a3t@newsbf02.news.aol.com> <4j3r1f$1tc4@seminole.gate.net> <4j43mu$m9t@freenet-news.carleton.ca>
  9. NNTP-Posting-Host: navajo.gate.net
  10. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  11.  
  12. Anthony Hill (an171@FreeNet.Carleton.CA) wrote:
  13. : 
  14. : doug haire (dhaire@gate.net) writes:
  15. : > RobertN141 (robertn141@aol.com) wrote:
  16. : > : I find this information very interesting. My company manufactures the 
  17. : > : AMQUEST HyperModem V.34.  This product will support up to 230,000 BPS
  18. : > : throughput and has a enhanced microcontroller architecture to better
  19. : > : compress
  20. : > : and decompress data.  The fundamental problem with many modems is that
  21. : > : they are all rated 28.8 V.34 115,200 max.  However, they lack the
  22. : > : horsepower
  23. : > : to handle above 88,000 bps throughput. Since in the past many people were
  24. : > 
  25. : > More hype.
  26. : > 
  27. : > Listen, first of all, I'd say V.34 modems (and even V.32bis modems) are 
  28. : > fully capable of handling a throughput speed above 88k. In fact, I know 
  29. : 
  30. :     Try running bi-dirrection transfer with both DTEs set to 115.2kbps
  31. : and apair of modems using the Rockwell controller.  You'll find that they
  32. : do tend to have problems keeping up.
  33.  
  34. Unfortunately (or maybe fortunately), I don't have two Rockwell based 
  35. V.34 modems to test this. I have noted that my Couriers do slow down on 
  36. bi0directional transfers of highly compressible files but I have no way 
  37. to compare to a paired Rockwell set.
  38.  
  39. : > this is true. Second, I'd like to point out that comm overruns are a 
  40. : > fault that lies with the operating system software of the CPU. I recently 
  41. : > tested this on a comparison with a large file and two different platforms 
  42. : > (MS-DOS and Linux) on the same CPU. The sender was a  486dx4/100 CPU running 
  43. : > MS-DOS and using a USR Courier V.34 v.everything. The receiver was a 
  44. : > 486sx33 with another Courier (same model) running linux and MS-DOS 
  45. : > (separate partitions, dual boot). Modems were connected via an 8 ft 
  46. : > telephone cable and synched at 33,600 bps with V.42 LAPM and V.42bis 
  47. : > compression.
  48. : > 
  49. : > The linux platform received the file with no errors, no comm overruns, no 
  50. : > garbled subpackets, no problems.
  51. : > 
  52. : > The MS-DOS platform received constant errors such as comm overruns and 
  53. : > garbled subpackets.
  54. : 
  55. :     It isn't so much a case of what operating system you're using, but
  56. : what sort of software is talking to you're com port.  Dos doesn't come
  57. : with any useful com drivers, so everyone writes their own, to varying
  58. : degrees of success.  A really well writing DOS com driver can run at up to
  59. : 115.2kbps with a 16450 UART without getting any errors.  Of course, well
  60. : writing DOS com software can be kinda rare.  Linux, on the other hand,
  61. : does use a com driver (like just about every other OS out there).  Again
  62. : though, overruns may occure with one com driver and not the other.
  63.  
  64. Generally speaking, the DOS drivers suck big time (I just love technical 
  65. terms). I used the linux platform as a comparison. I ran other stuff in 
  66. the background while transferring these files on the linux system 
  67. (installing software on another login) and got no glitches whatsoever. I 
  68. did no multi-tasking on the DOS platform at all.
  69.  
  70. I think it's pretty clear...
  71.  
  72. : > When the common computer software platform is capable of handling 115200 
  73. : > properly perhaps we can then consider the 230k UART speed.
  74. : 
  75. :     Software IS capable of 115.2 speeds now.  In fact, with the right
  76. : hardware it's capable of MUCH higher DTE speeds then that (eg Hayes ESP
  77. : cards will run at up to 900kbps or so without overruns).  The problem is
  78. : that 16550 UARTs can't really go faster then 115.2kbps.  Both 16650s and
  79. : 16750s can, and both of those chips have on board flow control, which will
  80. : completely eliminate com overruns.
  81.  
  82. Well, we agree to some extent here (I say it isn't just the hardware but 
  83. the software as well) and we also agree that it isn't necessary to open a 
  84. port higher than 115200 in the "real world" (I read your other post 
  85. addressing this).
  86.  
  87.